This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
The company I work for has been having a strange problem with profile documents for over a year now.
Every once and awhile, one of our customers will complain that their notes application's settings (which are stored in a profile document) will vanish, rendering the system unusable until they are fixed/re-entered.
We could never figure out why this happened - until now. It's a flaw Lotus introduced in 5.0.8 with the $ConflictAction="2" field that is mandatory for all profile documents.
As you know, profile documents cannot have replication conflicts. If a "conflict" were to occur, I believe that the $ConflictAction="2" stops the conflict, and instead uses the "newer" document, and deletes the other one. This makes (sort of) sense, since there is no way to clean up replication conflicts for profile documents.
The problem occurs when users or administrators make new replicas of databases. An end user can make a new replica of a large database that will take quite a bit of time. They get impatient and open the database before it has 100% completed replicating.
Unfortunately, if the "settings" profile document has not replicated to the new replica yet, the "@GetProfileField" call will MAKE A NEW BLANK ONE! Once this new, blank profile document replicates back up to the server, the $ConflictAction="2" uses the blank one and overwrites the original correct one because the blank one has a newer modified date!
I can't think of *any* fix to this problem without a Lotus bug fix (which is doubtfull).
In any event, we'd like to figure out some sort of workaround to prevent this from happening again. Any ideas? :-(